We require contributors to sign our Contributor License Agreement, and we don't have @HactarCE on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

I no longer work at Zed, but I'm glad someone picked this up. Thank you so much for continuing this!

@cla-bot check

The cla-bot has been summoned, and re-checked this pull request!

Hey @marcocondrache 👋

Thanks for opening this. I was looking at #5039 last week to pick it up and see if we can ship it, so it’s great to see you continuing the work from #45008 !

I paired briefly with @cole-miller today, and we’re planning to update Byron/trash-rs to centralize all trashing and restoring logic there. That crate already provides restoration logic, and both Byron/trash-rs#109 and Byron/trash-rs#128 explore returning the actual item that was trashed, for both Linux and macOS, so that it can be restored. With those changes, it seems we’d only be missing restoration support for macOS as well as returning trashed items on Windows.

If that goes well, we may update these PR changes accordingly, assuming you’re comfortable with that. Let me know if you’re up for some pairing time 🙂

Hey @dinocosta, thanks for checking this - I had exactly the same idea.

Instead of copying to a temporary folder like in #45008, we can reuse the OS trash and avoid doing the work twice. The current state of the PR already does this (at least on macOS), and I’ve been exploring how to implement it on Linux and Windows as well.

I looked at trash-rs when starting the PR, but I didn’t really like the implementation. It requires passing around handles to trashed items, which gets inconvenient, especially for remote worktrees since they’d need proto serialization. I’m currently working on a separate trash crate that abstracts the platform implementation like trash-rs does and allows restoration by only knowing the old path (I can explain how this works).

I love pairing sessions, so we can arrange a meeting.

Quick update for anyone following along 👋

Just chatted with Marco today and we’ve decided that, while we’re waiting for the filesystem‑related changes that allow tracking trashed files and directories to be reviewed and approved (zed-industries/trash-rs#1, zed-industries/trash-rs#2, as well as the changes in https://github.com/zed-industries/zed/tree/5039-fs-update and https://github.com/zed-industries/zed/tree/5039-fs-restore), we’ll use this pull request to nail down the undo/redo system and add support for undoing and redoing the following operations:

• Moving
• Renaming
• Creating

We may eventually even ship these first and, once the filesystem‑related changes are reviewed and shipped, open a new pull request adding support for undoing and redoing file and directory trashing 🙂⁠

@dinocosta thanks a lot for reviewing this!

• I extracted the logic into undo.rs to make it easier to manage and reason about. I've got inspired by https://developer.apple.com/documentation/foundation/undomanager
• I looked at how VSCode handles conflicts during undo operations. It simply shows a toast notification with the raw error message, I think we can do something similar.
• I updated the revert logic for ProjectPanelOperation::Batch so it attempts to undo all operations and then collects any errors that occur. We still need to decide how we want to surface or handle errors in this particular case.